出品丨自主可控新鲜事
作者丨吴夏，腾讯云 TDSQL 高级工程师
内容经授权转载自CSDN（ID：CSDNnews）
正文共4777字，建议阅读时间10分钟
随着国家有关部门近年来陆续出台相关政策指导文件，推动探索安全可控的金融科技产品，加强银行业信息安全建设，国内众多金融政企机构开始探索借助数字化技术，来实现原有 IT 系统的转型升级，从而实现降本增效，已经成为行业发展的共识。
近日，腾讯对外透露其自研的金融级分布式数据库 TDSQL 的金融政企用户数突破 600 家。作为一款自主研发的金融级数据库，TDSQL 正在成为众多金融机构数字化升级过程中的一大担当。本文将以国内某大型金融机构的数据库真实迁移的实践出发，分享国产数据库的技术架构、迁移历程以及优化措施。
国产数据库解决的问题
传统集中型数据库，成本高、扩容难、性能受限，传统模式下靠采购高端设备以及增加硬件来保证数据库可用性和扩展性的方案正面临越来越大的压力。而自主可控分布式数据库具备高可扩展性、高性能、高可用等特性，可以很好地满足产业互联时代线上化、高频、多维度、高并发的场景需求，能够帮助金融机构在解决技术瓶颈问题的同时，助力实现降本增效，而节省下来的成本效率，银行可用于业务快速创新和迭代，发展互联网线上化业务，在时间和空间上扩大银行业务服务版图。
成本方面，国产分布式数据库同样表现优势明显。举个例子，基于 TDSQL 的新系统在硬件层面全面采用 x86 服务器，取代传统商用数据库所需的大型机、小型机，成本优势明显。最新客户案例数据显示，张家港农商行采用 TDSQL 分布式数据库架构后的硬件成本，只有传统架构成本的 1/5 甚至更低。而微众银行公布的数据看，单客户 IT 成本能节省为传统商业数据库架构的 1/10。
作为技术与知识产权自主可控的金融级分布式数据库，可满足国家对金融安全自主可控的要求。通过核心技术升级，以新一代分布式数据库解决过去难以解决的业务问题，同时实现自主可控，是企业数字化转型的趋势选择。
如何迁移？
在金融业务场景中，数据库迁移升级、数据分发与数据备份是数据库系统必不可少的基本功能。其中前者是实现数据解耦及汇总的重要基础，例如保险行业常见的总分系统架构，多个子库需要实时的将业务数据同步至总库汇总查询；银行核心交易系统中，需要将交易数据实时同步至分析子系统进行报表，跑批等业务员操作。而数据备份则是数据安全的基石，更是金融业务数据的生命线。作为一个金融级数据库产品来说，TDSQL 在技术层面沉淀了针对数据库数据迁移、分发、同步和备份的 TDSQL-MULTISRCSYNC（TDSQL-多源同步）解决方案，为数据库系统国产化转型的高可用、高可靠提供了有益参考。
▐ TDSQL 多源同步核心架构：数据迁移与同步的关键逻辑
分布式数据库 TDSQL 是腾讯打造的一款分布式数据库产品，具备强一致、高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能 DBA、自动化运营、监控告警等配套设施。
TDSQL-MULTISRCSYNC（多源同步），是高性能、高一致，支持多种异构数据平台的数据分发服务。该服务支持以 TDSQL 作为源端的数据实时同步分发至 MySQL、Oracle、PostgreSQL、消息队列等平台，同时也支持以 TDSQL 作为目标端，将 MySQL 或者 Oracle 的数据实时同步至 TDSQL 中,并且部署灵活，支持一对多，多对一等多种复制拓扑结构。
多源同步模块典型的基于日志的 DCD 复制技术，其系统架构如下：
从上图我们可以看到，整个系统可以大致地分成三个部分：producer，store，consumer。
- producer：增量日志获取模块，主要负责解析获取源端的增量数据改动日志，并将获取到的日志解析封装为 JSON 协议的消息体，投送至消息队列。当源端是 MySQL 或者 TDSQL 时，获取的增量日志为 binlog 事件，这里要求 binlog 必须是 row 格式且为 full-image。当源端是 Oracle，producer 从 Oracle 的物化视图日志中获取增量数据并进行封装和投送。这里 producer 在向消息队列生产消息时，采用 at-least-once 模式，即保证特定消息队列中至少有一份，不排除在队列中有消息重复的情况。
- store：消息队列中，因为数据库系统日志有顺序性要求，因此这里所有的 topic 的 partition 个数均为 1，保证能够按序消费。
- consumer：日志消费和重放模块，负责从消息队列中将 CDC 消息消费出来并根据配置重放到目标实例上。这里因为 producer 端采用 at-least-once 模式生产，因此消费者这里实现了幂等逻辑保证数据重放的正确。
▐ 核心特性：高性能、高一致、高可用
一、高性能保障：基于行的哈希并发策略
金融业务场景中，往往对数据的实时性要较高，因此对数据同步的性能提出了比较高的要求。为了解决这样的问题，consumer 采用了基于行的哈希并发策略实现并行重放。下面以 binlog 消息为例来说明该策略的实现。
数据库系统在记录 binlog 时，按照事务的提交顺序将行的改动写入 binlog 文件，因此按照 binlog 文件记录事件的顺序进行串行重放，源端和目标端数据库实例状态一定会达到一致。但是串行重放因为速度慢，在遇到如批量更新等大事务时，容易产生较大的同步时延，适应不了对数据实时性较高的同步场景。为了提高并发度，这里 consumer 按照每个行记录的表名和主键值进行 hash，根据 hash 值将消息投送到对应的同步线程中。这样乱序的重放会导致数据不一致吗？答案是不会的，因为虽然是将顺序的消息序列打乱了，但是同一行的所有操作都是在同一个线程中是有序的，因此只要每个行的改动执行序列正确，最终数据是会一致。这个过程如下图所示：
二、一致性保障：row 格式 binlog 事件的幂等容错
实现幂等逻辑的动机有两个：
- 因为生产者实现的是 at-lease-once 模式进行消息生产，因此 consumer 这里必须要能否处理消息重复的问题。
- 支持幂等逻辑后，便于数据的修复，且在数据同步的过程中不需要记录镜像点，便于运维。
这里幂等逻辑的设计原则就是，保证按照 binlog 事件的意图去对目标实例进行修改。如 insert 事件，其意图就是要在数据库中有一条 new 值标识的记录；update 事件的意图就是，数据库中没有 old 值标识的记录，只有 new 值标识的记录；delete 操作也是同样，其结果就是要求目标数据库中，不包含 old 值标识的记录。因此针对 insert，update，delete 操作，其幂等逻辑如下：根据上图可以看到，当出现主键冲突时，insert 操作会转变成 delete+insert 操作来保证 insert 动作执行成功。另外图中的影响行数小于 0 或者等于 0 标识执行 SQL 出错和主键冲突。
从上图我们可以看到，update 操作的幂等处理，其实就是保证了在数据库中，只能有 new 值产生的记录。
这个过程中，delete 结束后大于 0 就成功；小于 0 就是失败；等于 0 的时候我们认为它可能没有匹配到行，这个时候我就按照主键操作——因为删除的操作最终的结果就是目标一定没有了当前删除的消息主键所标识的这一行——这条操作完成后，DB 里一定没有这行数据，因此仅仅是按照主键进行删除就可以了。这个时候如果影响行数大于 0，则删除成功。如果等于 0，就认为按照主键去匹配，本身删除不到，匹配不到——意思是本身目标就没有这条要删的主键所标识的数据——所以实际上它的结果跟要做完删除的结果，影响是一样，也就结束这一条删除的幂等。
这一套同步服务，一定是高可用的，体现在两个方面：1、灾难的情况下，本身消费者的服务能够在假如机器出现一些不可恢复的故障时能够及时地感知并且自动迁移和切换；2、要应对本身常规的扩容——垂直扩容或者水平扩容的伸缩性需求，这也是我们比较强调，这一套同步服务要能够兼容各种灾难情况和常规的运维场景下各种各样的要求来做到服务的高可用。重点针对数据库迁移同步的场景而言，TDSQL 多源同步提供多机容灾保护机制：消费者高可用保障层面，一方面消费者服务本身无状态，所有的任务下发通过 MetaCluster 实现，可以通过多台机器去部署同步服务，这套容灾机制通过 manager 进程来实现，也就是说当整个机器掉电，运营这个机器的 consumer 已经不存活，这个时候这些 consumer 在 MetaCluster 上的存活节点的失效就会被其他机器的 manager 节点感知——认为另外一些机器的 consumer 已经不存活，这个时候就会把任务接管过来，并且在自己机器上重新拉起这些服务。二是我们要做到同一个数据同步的链路不能在两台机器上同时拉起，这是一个互斥的要求。高可用机制会通过一些像唯一标识或者当前的分派节点做到，同一个数据同步的任务在被拉起的时候一定是发生在不同的机器上来实现漂移与互斥的操作，这个多机容灾保护总体上就是通过 MetaCluster 和监控的进程，比如说 manager 这样的服务进行协调完成，保证在机器级别灾难或者其他灾难情况下这些任务能够在十秒以内成功迁移到其他的存活节点上。
TDSQL 多源同步解决方案，过去几年中，已经在众多金融政企用户中得到成功实践，帮助用户高效平稳的实现国产数据库迁移替换。而作为 TDSQL 模块中核心的产品服务之一，除了可以实现数据库全量平稳迁移，TDSQL 多源同步方案还具备支持数据分发、备份等场景应用能力，用户基于这些能力，探索出各类安全高效实现对业务的数据智能化驱动的姿势。用户可以通过多源同步对业务进行分布式的改造，直接通过实时同步将单实例往分布式的架构上迁移。比如说保险客户通过多个分库、多个分片区或者多个单的业务、逻辑上的划分，把这些数据通过 TDSQL 这套服务同步到全量库里面。
以某大型互联网保险公司为例，基于 TDSQL 多源同步迁移方案，实现了多对一的一拓扑结构，可以非常高效、稳健地将公司多套大区的业务数据汇总到一个全量库里面，继而实现了对整体数据进行报表分析和抽取。某大型消费金融公司，在将核心数据库替换成 TDSQL 后，利用 TDSQL 多源同步服务进行不同数据库实例之间的同步。这样的操作带来业务上的两大层面驱动：第一个是风控，通过将增量的数据投送到下游消息队列里面，可提升智能风控的准确率与效率；第二，实现了数据仓库，用户利用多源同步这套系统，将业务实时生产库里面的数据源源不断地、实时地投入到数据仓库中，继而实现 OLAP 类的业务，为业务提供智能化决策分析支持。2019 年，张家港行基于 TDSQL 打造的新一代核心业务系统，成功上线后便成为业界关注的焦点。将银行传统核心系统数据库迁移到腾讯云 TDSQL 数据库后实现了代差级的降本增效。
在这样的金融级高度敏感业务系统迁移实践中，TDSQL 的性能和安全的迁移服务策略得到良好的验证。在张家港行数据库迁移实践中，核心交易集群是 TDSQL，TDSQL 多源同步方案通过内部的局域网，将存量和增量数据，写入到备份机房，同时也通过全量的数据校验服务保证数据源、目标是完全一致来进行风险控制。当核心交易系统如果出现一些小概率不可恢复的灾难时候，系统可以在短时间内将交易的服务全部切换到备份机房的 Oracle 上，作为银行传统核心系统数据库迁移的安全兜底方案，最后确保数据库顺利迁移。数据库迁移涉及大量核心数据信息，“快”和“稳”缺一不可。多源同步服务作为 TDSQL 内置功能特性，以某省广电局迁移案例为例，TDSQL 多源同步迁移服务通过重新部署业务系统的迁移方式，从迁移准备、迁移评估、方案设计、资源准备及数据库改造、迁移实施、结果验证一共只使用 30 天。其中最为关键的资源准备及数据库改造环节用时 7 天！将客户的业务系统数据库从 Oracle 迁移到 TDSQL，TDSQL 的性能满足了客户面临的现有的业务压力。而业务系统迁移过程中对数据完整性保障，为后续新业务系统运维提供了良好的数据基础。以某互联网人寿保险公司为例，该用户在公有云 TDSQL 上的实例是其核心的生产环境，云下同时也部署了一套 TDSQL 系统，通过多源同步这套系统，用户实现了云上的生产环境和云下的生产环境灾备同步，这相当于是，实现了跨城同时也是跨数据中心的数据灾备功能。
基于高一致、高性能、高可用这“三高”的特性，TDSQL 多源同步帮助用户业务实现金融级别或者金融场景的数据对外解耦、数据分发、迁移、同步等能力，并通过这些能力，融合到用户业务的数字化升级当中。TDSQL 多源同步作为 TDSQL 产品服务体系的核心模块，既是如关键桥梁般的功能，也是帮助衍生业务价值的服务，在数据库国产化中从分布式改造、迁移、备份到后续同步、分发等，服务用户迁移到投产、生产运营的全流程。这也是 TDSQL 在多年的实践打磨下，呈现的产品化优势。内容经授权转载自CSDN（ID：CSDNnews）